AWS VPC, Subnet 과 Gateway

이전 글에서 VPC, Private Subnet, Public Subnet이 뭔지는 훑어봤고,
이제 자연스럽게 이런 궁금증이 생긴다.

  • 사설망인 VPC가 바깥 인터넷이랑은 어떻게 통신하는지
  • VPC 안에서 EC2끼리, RDS랑은 어떻게 통신하는지

먼저, VPC를 네트워크 관점에서 다시 보기

VPC를 네트워크 용어로 풀어보면 대충 이렇게 묶인다.

  • CIDR: 10.0.0.0/16 이런 식으로 IP 대역을 표현하는 방식
  • VPC: 이 CIDR 대역을 통째로 쓰는 내 회사 전용 사설망 하나
  • Subnet: 그 VPC CIDR을 다시 잘라서 쓰는 작은 네트워크 조각
    • Public / Private 구분은 라우팅 + 게이트웨이 설정으로 갈림
  • Route Table: “이 IP 대역으로 가는 트래픽은 어디로 보낼지” 정해놓은 길 안내판
  • Gateway: 서로 다른 네트워크 사이를 연결해주는 출입구

AWS 입장에서 보면:

  • VPC = 내 사설망
  • Subnet = AZ 안에 있는 작은 방
  • Route Table = 방마다 걸려 있는 안내판
  • IGW / NAT GW = 건물 밖으로 나가는 문

1. VPC는 원래 완전 고립된 사설망이다

VPC는 이름 그대로 Virtual Private Cloud라서
처음 만들었을 때 상태만 놓고 보면, 그냥 외부랑 완전 단절된 사설망이다.

  • 인터넷으로 나갈 길이 없음
  • 다른 VPC나 온프렘이랑도 연결 안 돼 있음
  • 심지어 같은 AWS 계정 안의 다른 VPC랑도 바로 통신 안 됨

이걸 외부(인터넷 / 다른 네트워크) 와 이어주는 역할을 하는 게
Internet Gateway, NAT Gateway, VPC Peering, VPN, Direct Connect 같은 애들이다.

이 중에서 “인터넷” 관점에서 중요한 애가 IGW / NAT라서 그 둘을 먼저 정리한다.

2. IGW (Internet Gateway) – VPC와 Network 통로

IGW는 VPC 입장에서 보면
내 사설망을 공인 인터넷이랑 이어주는 출입문이다.

IGW가 하는 일

  • Public Subnet에 있는 EC2에 브라우저로 접속할 때
  • EC2에서 npm install, apt update 같은 거 외부로 요청 보낼 때
  • ALB가 인터넷에서 클라이언트 요청을 받아올 때

이 모든 트래픽이 결국 IGW를 지나간다.
IGW가 없으면, 그냥 인터넷이랑은 단절된 네트워크라고 보면 된다.

IGW가 “접근을 막아주진 않는다”

IGW는 그냥 문이고,
그 문을 통해 들어오고 나가는 걸 필터링하는 건 다른 애들 역할이다.

현업에서 “게이트웨이 쪽에 WAF 붙여서 중국 IP 막았다” 같은 말을 들으면
거기서 말하는 게이트웨이는 보통 API Gateway / ALB / CloudFront 같은 L7 프록시 계열이다.

  • Internet Gateway
    • VPC ↔ 인터넷 사이를 이어주는 L3~L4 출입문
    • VPC 하나에 Attach 가능한 IGW는 1개
  • API Gateway / ALB / CloudFront
    • HTTP/HTTPS 요청을 받아서 서비스나 백엔드로 전달해주는 리버스 프록시
    • 여기다가 WAF 붙이고, IP 차단, 레이트 리밋 등을 거는 것

3. NAT Gateway – Private Subnet과 Network 통로

Private Subnet은 Public Subnet과 달리 공인 IP가 없기 때문에 Private Subnet은 인터넷에서 직접 들어올 수는 없는 서브넷이다.

그런데 내부 서버도:

  • 패키지 업데이트 해야 하고
  • 외부 API 호출해야 하고
  • S3에서 뭔가 받아올 수도 있고

어쨌든 밖으로 나갈 일은 많다.
이걸 도와주는 게 NAT(Network Address Translation) Gateway다.

NAT가 하는 역할

NAT는 “사설 IP ↔ 공인 IP”를 바꿔 끼워주는 애다.
예를 들어 Private Subnet에 10.0.1.15 라는 EC2가 있다고 해보면,

  • 내부에서 실제로 나가는 요청은 10.0.1.15:5000 → 8.8.8.8:80
  • NAT가 이걸 3.123.45.67:62000 → 8.8.8.8:80 이런 식으로 바꿔서 인터넷으로 내보낸다.
    (3.123.45.67은 NAT의 공인 IP 느낌)

외부 서버 입장에서는 “3.123.45.67이 요청 보냈네?” 하고 응답하고,
그 응답이 다시 NAT로 돌아오면 NAT가 내부 세션 테이블 보고
다시 10.0.1.15:5000으로 돌려보낸다.

“단방향”이란 게 무슨 뜻인지

NAT Gateway를 설명할 때 흔히 “단방향”이라고 말하는데,
이건 요청을 누가 먼저 시작하냐의 관점이다.

  • 내부에서 먼저 나간 요청에 대한 응답은 다시 돌아올 수 있음
  • 하지만 외부에서 먼저 Private Subnet으로 들어오는 건 막힌다

그래서 NAT를 통과해서 세션이 시작되는 방향이 항상 Private → Internet이고,
이게 단방향이라고 부르는 이유다.

NAT Gateway는 어디에 위치하냐

AWS 콘솔 상으로는 어느 서브넷에 NAT Gateway를 만든다고 되어 있어서
“이 서브넷 안에 있는 장비인가?” 싶은데, 실제론 좀 더 추상화된 매니지드 서비스 느낌이다.

  • NAT Gateway는 보통 Public Subnet에 만든다
  • 여러 개의 Private Subnet이 하나의 NAT Gateway를 공유해서 쓴다
  • AZ마다 NAT를 따로 두는 게 권장 패턴 (NAT Gateway는 AZ 수준 리소스라서)

라우팅 테이블에서는 대략 이런 구성을 한다:

  • Private Subnet Route Table 0.0.0.0/0 → NAT Gateway
  • Public Subnet Route Table 0.0.0.0/0 → Internet Gateway

트래픽 동선은 이런 식으로 흐른다:

Private EC2 → NAT GW → IGW → Internet
Internet → IGW → NAT GW → Private EC2 (응답만)

4. 인스턴스끼리는 어떻게 통신할까? – Route Table + AZ

이제 “VPC 안에서끼리” 통신 얘기

같은 VPC 안이면 기본적으로 내부 통신이 열린다

각 Subnet은 Route Table 설정을 가지고 있다.
Route Table을 보면 자동으로 하나 들어 있는 항목이 있다.

10.0.0.0/16  → local

이 엔트리는 지우지도 못한다. 여기 들어가 있는 CIDR 범위는 해당 VPC의 CIDR 블록 전체다. 이 말은: 같은 VPC 안에 있는 Subnet끼리는 CIDR만 맞으면 무조건 VPC 내부망(local) 을 통해 통신한다는 뜻이다.

그래서:

  • Public Subnet의 EC2 → Private Subnet의 RDS

  • AZ A의 EC2 → AZ C의 EC2

    전부 별도 라우팅 설정 없이 “local” 경로로 통신한다. 막고 싶으면 SG / NACL에서 막는 게 기본 패턴이다.

AZ가 달라도 인터넷을 타지 않는다

Subnet은 무조건 하나의 AZ에만 속한다.
그럼 AZ끼리 통신할 때 인터넷을 도는 거냐? 그런 건 아니고,

  • AWS가 AZ 사이에 전용 백본망을 깔아놓음
  • VPC 내부 트래픽은 이 전용선만 타고 돈다
  • 인터넷으로 나갔다 들어오는 구조가 아니다

그래서 AZ가 달라져도 보통 지연이 1~2ms 수준이고,
감각적으로는 거의 LAN 통신이랑 비슷하게 느껴진다.
대신 AZ 간 트래픽에는 소량의 요금이 붙는다.

정리하면

  • 같은 VPC, 같은 CIDR 안에서는.
    • Route Table의 local 엔트리를 통해 항상 내부망으로 통신
  • 통신 가능 여부는 결국
    • SG / NACL이 허용하냐로 결정

번외. Gateway vs Proxy – 헷갈릴만한 포인트 한 번에 정리

비슷하게 들리지만 하는 일이 꽤 다른 애들이라.
한 번 정리해두면 클라우드 아키텍처 볼 때 머리 정리가 잘 된다.

Gateway

  • 서로 다른 네트워크를 이어주는 출입문에 가까운 개념
  • 네트워크 계층(L3~L4)에서 동작하는 경우가 많다
  • AWS에서 예:
    • Internet Gateway: VPC ↔ 공인 인터넷
    • NAT Gateway: Private Subnet → Internet (요청 시작 방향이 내부)
    • VPN Gateway / Transit Gateway: VPC ↔ 온프렘 / 다른 VPC

Proxy

  • 같은 네트워크 안에서 요청을 대신 받아서 전달하는 중개자.
  • 주로 애플리케이션 계층(L7)에서 동작
  • AWS에서 예:
    • ALB / NLB: 리버스 프록시 + 로드밸런서
    • API Gateway: HTTP API 입구
    • CloudFront: 글로벌 캐싱 프록시 + 리버스 프록시

Gateway는 “경계”, Proxy는 “대리인” 정도로 생각하고 있다.

마무리

정리해보면

  • VPC는 기본적으로 완전히 고립된 사설망
  • 바깥 세상과 이어주는 통로는
    • Public 쪽은 IGW
    • Private 쪽 Outbound는 NAT GW
  • 내부 통신은 Route Table의 local 덕분에 자연스럽게 열려 있고,
    최종 허용/차단은 SG와 NACL이 담당
  • Gateway는 네트워크를 잇는 출입문 쪽 개념,
    Proxy는 요청을 받아 대신 전달해주는 애플리케이션 계층 개념